1. Field of Invention
The present invention relates generally to the field of software applications used on an information network (such as for example a cable television network), and specifically to flexible methods and apparatus for providing programming interfaces across a variety of different network configurations and protocols.
2. Description of Related Technology
Digital TV (DTV) is an emerging technology which utilizes digitized and compressed data formats (e.g., MPEG) for content transmission, as compared to earlier analog “uncompressed” approaches (e.g., NTSC). The DTV content may be distributed across any number of different types of bearer media or networks with sufficient bandwidth, including Hybrid Fiber Coaxial (HFC), satellite, wireless, or terrestrial.
Interactivity is a key feature offered by DTV. Interactive applications enhance viewer experience beyond the simple “watch-TV” experience historically provided by analog television transmission networks. Various standards have been defined in the interactive television (ITV) industry that specify how various interactive applications are created, the software modules are transmitted with television programs, received and presented to the viewer by the Consumer Premise Equipment (CPE).
DTV standards such as the OpenCable Application Platform (OCAP) middleware specification (e.g., Version 1.0, and recently released Version 2.0) require that applications be downloaded to CPE from the bearer or broadcast network in real-time. The OCAP specification is a middleware software layer specification intended to enable the developers of interactive television services and applications to design such products so that they will run successfully on any cable television system in North America, independent of set-top or television receiver hardware or operating system software choices.
As is well known, middleware generally comprises one or more layers of software which are positioned “between” application programs and the lower or physical layers of the network device. Middleware is commonly written for the specific requirements of the operator of the computer system, and the proprietary software purchased by the operator of the computer system. A key role of middleware is to insulate the application programs from the device specific details. By using middleware the application programmers need know very little about the actual network details, since they can rely on the middleware to address the complexities of interfacing with the network.
In the context of cable television networks, Video-on-Demand (VOD) is an example of a commercially important ITV application. This application is also a good example of an ITV application that requires software components that implement communications protocol specific to a cable network for interaction with a VOD server on the network side (e.g. at a cable headend). For example, in networks that use equipment from Motorola (previously General Instrument), APIs supporting DigiCipher™ network will be implemented. Similarly, in a cable network that is based on Scientific Atlanta's PowerKey™ Conditional Access system, APIs specific to that system will be used.
In general, a network-specific protocol is a protocol or method that is used to provide cable services that may or may not be based on a standard. The protocol tends to be different between cable operators. Other examples of network specific protocols include (but are not limited to) those used to support on-demand interactive session setup, video stream control, and pay-per-view (PPV) services.
Even with the separation of conditional access hardware from the video and audio decoding hardware on the typical digital receiver (as described for example in the CableCard specification), there are still network specific protocols that must be abstracted below the application layer, but above the middleware implementation.
Various methods are used in ITV applications to implement network specific protocols. In the OCAP context, two primary methods are employed to address these issues. The first method specifies a standard API interface to abstract the specific protocols, and requires that every implementation support this interface. One salient problem with this method is that when a consumer obtains the CPE from a retail store or similar source, the CPE has no knowledge of the network to which it will be attached, and is hence unable to implement the correct protocol(s) for that network.
The second method requires the application to implement the defined protocol within the scope of the application itself. This method requires the application developer to be familiar with all of the different protocols, and to produce multiple versions of the application for the different networks in which the application will be used. Additionally, for multiple applications to access these services, it would be necessary for each application to implement the same protocols, which is a significant waste of the limited resources of the CPE.
A number of other approaches to software and interface management are present in the prior art. Specifically, U.S. Pat. No. 6,728,963 to Forin, et al, issued Apr. 27, 2004 and entitled, “Highly componentized system architecture with a loadable interprocess communications manager” discloses a loadable interprocess communication manager and generally a computer operating system capable of supporting plural threads running in a computer having a working memory. The computer operating system includes a kernel resident in the working memory at link time and a loadable interprocess communication manager (resident at link time outside of the working memory and dynamically loadable into the working memory at run time upon request by one of the threads in one address space to communicate with an other thread in an other address space). The kernel includes a loader for loading the interprocess communication manager into the working memory in response to the request by the one thread. The computer further includes a storage memory separate from the working memory, the loadable interprocess communication manager residing at link time in the storage memory. The loader loads the interprocess communication manager from the storage memory to the working memory. The loadable interprocess communication manager is terminable from the working memory upon lack of a need for communication between threads in different address spaces.
U.S. Pat. No. 6,725,285 to Van De Muelenof, et al, issued Apr. 20, 2004 and entitled, “Communication system, controlling device and controlled device” discloses a communication system having a controlled device for which an abstract representation (AR) is provided as an interface on a controlling device. When the quality of the connection between the controlling device and the controlled device drops below a predetermined level, or if some similar criterion is met, the system selects a second controlling device which is better suited for controlling the controlled device, and generates a migration event to indicate this. The first controlling device transfers control over the controlled device to the second controlling device when it receives said migration event. This can be done by uploading the AR to the second controlling device, possibly supplemented with the current state of the AR to perform a transparent transfer.
U.S. Pat. No. 6,704,804 to Wilson, et al, issued Mar. 9, 2004 and entitled, “Method and system for communicating information among interactive applications” describes a group of protocols that establishes an information bus. The protocols allow various applications and components to plug into the information bus. As a member of the bus, each application or component can exchange information with any other application or component in a structured manner. The information bus is especially useful in interconnecting Java beans and applets in a Java virtual machine (VM) and in a distributive computer environment.
U.S. Pat. No. 6,543,050 to Letellier, et al, issued Apr. 1, 2003 and entitled, “Method and apparatus for enlarging DVB-CI functionality by enabling a direct access to the conditional access module” discloses apparatus and methods used in the Digital Video Broadcasting—Common Interface environment for accessing the Conditional Access Module (CAM). The host application handles objects of the Conditional Access (CA) through a private API. Each CAM may have its own private CA API, but the data channel remains identical irrespective of the CAM. This new mode coexists with two defined modes: (i) a low level Man-Machine Interface, and (ii) a high level Man-Machine Interface. If a set-top unit “understands” the private CA API, then it may access the features of the plugged CA through its private CA API Protocol. Otherwise, it remains on the standard API. With this extension, a set-top unit can have a Conditional Access user interface (UI) which fits into the overall UI of the unit. Thus, a broadcaster can ensure that its “look and feel” are respected on its set-top units. A manufacturer can build a set-top unit especially optimized for one or more CAs yet which is still able to run other CAs.
U.S. Pat. No. 6,408,342 to Moore, et al, issued Jun. 18, 2002 and entitled, “Communications framework for supporting multiple simultaneous communications protocols in a distributed object environment” discloses a communication framework supporting multiple communications protocols. The communications framework includes a remote procedure call class providing an interface for an “apply” method, the apply method referencing a remote object, an operation to be performed, and an argument list. The communications framework also has at least one remote procedure call transport deriving from the remote procedure call class; each remote procedure call transport provides an implementation for the apply method whose interface is provided by the remote procedure call class.
Despite the variety of techniques described above, the prior art does not disclose apparatus or methods to efficiently implement application software (such as that useful for ITV applications) that can be adapted to work on any network-specific communication protocol. This deficiency is particularly acute with respect to the HFC networks where different proprietary protocols exist for OOB communication with the head-end, and for certain Conditional Access functions. Accordingly, there is a need for an architecture and methods that enable registration of APIs, and provide mechanisms for applications to identify and use the appropriate APIs in any communications network regardless of its particular protocol(s). Such methods and apparatus would ideally simplify application development by eliminating the need to generate code to take into account all possible network protocols, thereby reducing host device CPU and memory requirements. Such methods and apparatus would also ideally provide software applications access to on-demand and encrypted services without having to know the details of the network specific protocol.